1. Field
The disclosed embodiments generally relate to relational database systems, and in particular to exclusive locks on rows of a database that span, and are transferable, across database session boundaries.
2. Brief Description of Related Developments
A relational or other object-relational database system stores the state of an instance or entity in a row of a table. The data in the rows can be changed via database manipulation commands. These data manipulation commands generally comprise short transactions, and can include for example insert/update/delete transactions. The short transaction database manipulation command will be followed by a terminal rollback or commit. The short transaction span is always within the bounds of a database session and can never span across database sessions.
Certain industry segments, such as for example, land information management, utilities management, hydrographic and aeronautical charting, and concurrent or collaborative engineering, require long transactions. A long transaction generally comprises a set of database manipulation commands that can span across the boundary of one or more database sessions. The changes made during the course of a long transaction can be made externally visible from time to time by explicitly committing the changes made. This is in essence, a sequence or series of short transactions.
For example, in many geographic information service (“GIS”) applications, there is a need for a user to hold on to, or maintain control of a row for a period of time. Data updates or edits in these systems can take hours, days or months. Thus, these long transaction updates can span across multiple sessions and even database shutdowns. During the time that the user controls the row, no other user should be able to implement any changes to the row, or even delete the row. As the user makes changes to the row, the changes can be made available to others for viewing, but not for updating. Eventually, the user will relinquish the hold on the row, at which point another user can access the data.
Database locking mechanisms, as the term is commonly understood, are not sufficient for long transactions. In some applications, it can be desirable to perform database update operations consistently over multiple database transactions spanning across multiple database sessions. The current short transaction locks cannot allow this type of functionality to be achieved. Long transaction management has generally included versioning. The updates/changes are persisted for long periods of time and stored in the database as different revision sets. When a user initiates a transaction, a new version of the data is created, while a copy of the old data is maintained. The results of the long transaction are stored persistently.
For example, the Oracle Workspace Manager (OWM) can solve project collaboration requirements through versioning of database rows/instances. OWM stores workspace/version related metadata and other information to maintain concurrency and consistency. However, this version related information is not relevant for locking purposes. The database can hold different versions of the same record in revision sets. Feature instances can be locked in a specific revision set and are intended to eliminate conflicts between parent and child revision sets. However, the locking provided by OWM is either database session based or workspace based. There is no way to associate and propagate a short transaction lock across database sessions.
It would be advantageous to enable a light-weight locking model in a database that provides a simple, high-performance solution that lets a user hold on to an exclusive update lock on selected rows of a database table for extended periods of time, that spans and is transferable, across short transaction boundaries and session boundaries.